In a networked environment, users have access to resources on the network. In order to access these resources, the network uses a security process requiring a user to log onto the network with a user identifier and password. After network verification, the user has access to the resources on the network.
Oftentimes, organizations wish to restrict generalized access to resources on the network to prevent security breaches, such as infiltration and corruption, as well as to ensure proper management, such as configuration, administration, operation and monitoring of resources. Prior attempts to restrict access include the use of policy-based authorization or role-based authorization. Policy-based authorization is a technique that assigns access control policies to a user or group of users for permitted actions on the resources, that is “permissions”. The permissions may include a variety of actions, such as starting, stopping, editing, writing, reading, etc. a given resource.
Role-based authorization is an alternative approach to access control that is based on assigning users to “roles”, where a role defines a collection of specific actions that can be performed on a specific set of resources. In a typical role-based system, access to an object within a computer system is provided to the members of a group that all have the same “role”; that is, all subjects belonging to a given role have the same privileges to access various objects within the system. Individuals are then granted access to objects by being assigned membership in appropriate roles. Role-based access control is preferred in most enterprise situations, since the various roles can be defined to align with various responsibilities and duties within a given organization (e.g., in a business, the roles may be “marketing”, “accounting”, “engineering”, and the like).
While preferable for these reasons, role-based access control to enterprise applications is provided in only a static configuration. That is, the set of users and the roles associated with each user are fixed at compile time. Additionally, the various functionalities associated with each role (hereinafter referred to as “features”) are also fixed at compile time. As a result, a user only gains use of a feature if one of the user's roles is associated with that feature at compile time.
Thus, it would be desirable to provide dynamic management of these functions, i.e., allowing for modifications of the roles assigned to users, as well as the features assigned to roles, during runtime of enterprise applications.